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COMPUTER-READABLE MEDIUM, METHOD AND COMPUTER SYSTEM FOR 
ACCESSING A NETWORKED PERIPHERAL DEVICE 

TECHNICAL FIELD 

[0001] This invention relates to network technologies and, more particularly, 

to a computer-readable medium, method, and system for accessing a networked peripheral 
device. 

BACKGROUND 

[0002] Computer systems generally comprise a storage management file 

system to enable a user to store and retrieve information. For example, a file system generally 
enables a user to create, modify and delete files; identify stored files by a symbolic name 
rather than specifying a physical storage device name; and view the information logically 
rather than with a more detailed physical view. The file system generally manages 
information via a device driver which manages a storage abstraction of a storage device. For 
example, based on a file system layout on the storage device, the device driver manages 
storage and retrieval of information using file system metadata information. 

[0003] Network file sharing is a method for transferring information over a 

physical network medium via a transport protocol. A transport protocol generally comprises 
a network file sharing protocol that enables remote operations such as opening, creating, 
reading, writing, and closing data files. In operation, a file sharing server generally runs on 
top of an existing file system such that network file sharing requests or calls are passed fi-om 
the file sharing server to the file system. Because file systems generally comprise the same 
set of functions (i.e., open, read, create, write, etc.), a network sharing server can run on top 
of virtually any file system. Thus, in operation, based on the file system layout of a local 
storage device, the file system enables remote data management operations by responding to 
network file sharing calls received firom a network sharing server. 

[0004] However, various types of storage mediums and associated devices, 

especially peripheral devices such as compact disc (CD) recorders, digital versatile disk 
(DVD) recorders, and other types of peripheral device recording systems, do not readily 
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accommodate writing or recording data across a network. For example, blank CDs and 
DVDs generally do not have a file system layout recorded thereon. In operation, recording 
information to blank CDs and DVDs generally comprises "pre-mastering" such that the 
content to be stored on the blank mediimi is known ahead of time. Thus, there is no format 
operation performed on the medium and no file system metadata recorded onto the medium. 
A software application for writing information to a medium such as a blank CD or DVD 
generally creates an image of the content that will be stored on the blank medium block-by- 
block and commxmicates directly with a disk driver to issue commands to write the content to 
the medium in this sequence of blocks, thereby bypassing any file system. Thus, because the 
file system is bypassed, a network file sharing infi-astructure does not enable remote data 
management. 

SUMMARY 

[0005] In accordance with an embodiment of the present invention, an 

input/output (I/O) request processing system comprises a drive command module adapted to 
receive an I/O request referencing a local peripheral address for processing of the I/O request. 
The system also comprises a redirector communicatively coupled to the drive command 
module. The redirector is adapted to automatically convey the I/O request over a 
communication network to a remote peripheral device for processing of the I/O request. 

[0006] In accordance with another embodiment of the present invention, a 

method for input/output (I/O) request processing comprises receiving an VO request 
referencing a local peripheral address for processing of the I/O request. The method also 
comprises automatically invoking a redirector adapted to convey the I/O request to a 
communication network to enable processing of the VO request by a remote peripheral 
device. 

[0007] In accordance with another embodiment of the present invention, an 

input/output (I/O) request processing system comprises a drive command module adapted to 
receive a command to record data to an optical medium. The system also comprises a 
redirector communicatively coupled to the drive command module. The redirector is adapted 
to receive the drive command fi-om the drive command module and automatically format the 
command for processing by a remote optical drive. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0008] For a more complete understanding of the present invention, the 

objects and advantages thereof, reference is now made to the following descriptions taken in 
connection with the accompanjdng drawings in which: 

[0009] FIGURE 1 is a block diagram of an example of various software and 

hardware modules for enabling processing of an input/output request issued by client 
application according to embodiments of the invention; 

[0010] FIGURE 2 is a block diagram of a device that may run a client 

application for issuing input/output requests implemented according to embodiments of the 
invention; 

[001 1] FIGURE 3 is a block diagram of an example of a device interconnected 

with a peripheral device for processing input/output requests implemented according to 
embodiments of the invention; and 

[0012] FIGURE 4 is a message flow diagram illustrating an example of 

processing of an input/output request in accordance with embodiments of the invention. 

DETAILED DESCRIPTION OF THE DRAWINGS 

[0013] The preferred embodiment of the present invention and its advantages 

are best understood by referring to FIGURES 1 through 4 of the drawings, like numerals 
being used for like and corresponding parts of the various drawings. 

[0014] For a peripheral device, e.g., an optical disc drive, it is desirable to 

enable client applications executing on various host devices to share access to the peripheral 
device over a network. It is further desirable to have the capability to communicate with the 
peripheral device over the network as if it is a local device. 

[0015] Many software appHcations communicate with a peripheral device of a 

computer system. To faciUtate such commimications, a device driver is used to control a 
hardware component of a peripheral device. A device driver is generally responsible for 
accessing one or more hardware register(s) of the peripheral device and may include an 
interrupt handler to process hardware intermpts generated by the peripheral device. 
Application programs often use a software layer commonly referred to as an application 
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programming interface (API) for interfacing with a peripheral device and for managing 
appropriate device driver calls. For example, the small computer system interface (SCSI) 
pass-through interface (SPTI) API, is implemented as a low-level portion of an operating 
system (O/S) kemel. Alternatively, the advanced SCSI peripheral interface (ASPI) API, is 
implemented as (a) file(s) loaded during application run-time. Other applications may 
communicate with a peripheral device by a proprietary device driver. 

[0016] An input/output (I/O) request issued by a client application and 

directed to a peripheral device is ultimately processed by a device driver adapted to format the 
I/O request for delivery to the targeted peripheral device regardless of whether the device 
driver is implemented as a proprietary device driver or an API. In doing so, a bus driver, e.g., 
an integrated device electronics (IDE) bus driver, a SCSI bus driver, or the like, that 
communicatively interfaces with the peripheral device is invoked. An I/O request identifies a 
particular peripheral device by way of one or more peripheral identifiers or attributes included 
within or referenced by the I/O request. As referred to herein, a software layer that receives 
an I/O request, and processes the request for execution with a targeted peripheral device, is 
referred to as a drive command module (DCM). A DCM may comprise part of an. operating 
system or, altematively, may be implemented as run-time software modules. In general, a 
DCM receives an I/O request and identifies an appropriate bus driver by way of a local 
peripheral device address associated with the targeted peripheral device. Assignment of a 
local peripheral device address with the I/O request may be had by including the address 
within the I/O request, or referencing, e.g., by a pointer, the peripheral device address within 
the I/O request. A DCM is adapted to process an VO request issued by a client application, 
and execute one or more drive commands with the peripheral device targeted by the I/O 
request. A drive command issued by a DCM corresponds to a received I/O request and is a 
lower-level, machine processible representation of the I/O request. Embodiments of the 
present invention enable I/O requests issued by a cUent application to be processed with a 
remotely located peripheral device in a manner that is transparent to the cHent application. 

[0017] Embodiments of the present invention may be better understood with 

reference to FIGURE 1 illustrating a block diagram of various software and hardware 
modules for enabling the remote processing of an VO request 15 issued by a client application 
10. A system 150 comprises a host device 100, e.g., a computer system and a network- 
connected device 101. Chent apphcation 10 executes on host device 100. In the illustrative 
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example, the descriptions of system 150 will be made with reference to a DCM 20 
implemented as an SPTL Accordingly, formatting of an I/O request 15 issued by client 
application 10 is described with reference to the SPTI protocol. Processing of an I/O request 
by an application that interfaces with another implementation of a DCM, e.g., ASPI, 
WINDOWS32 API, etc., may be performed in a similar manner in accordance with 
embodiments of the invention, and may be implemented for any drive conmiand module now 
known or later developed. 

[0018] According to one embodiment of the present invention, appUcation 10 

generates and issues I/O request 15 comprising a local peripheral address and conveys I/O 
request 15 to DCM 20. As referred to herein, a local peripheral address is a peripheral 
address associated with an originator of I/O request 15. In the illustrative example, I/O 
request 15 is issued by client application 10 running on device 100, and device 100 comprises 
the I/O request originator device. A call to a bus driver, e.g., a SCSI bus driver, is made by 
DCM 20 in an attempt to convey FO request 1 5 to a local adapter in accordance with the local 
peripheral address of I/O request 15. In the illustrative example, device 100 comprises two 
peripheral devices 80 and 81 having respective peripheral addresses A and B. For illustrative 
purposes, assume I/O request 15 includes or references a local peripheral address C of host 
device 100 at which no peripheral device is located. The absence of a peripheral device at 
peripheral address C is illustratively designated with dashed lines. The absence of a 
peripheral device at peripheral address C may, for example, be realized as an empty host 
adapter slot within device 100. 

[0019] In accordance with an embodiment of the invention, a bus driver 

network redirector 120, rather than a conventional bus driver, is invoked by a bus driver call 
made by DCM 20. Redirector 120 may, for example, be identified by DCM 20 as a bus 
driver by assignment of a bus driver label, e.g., a bus driver file name, to redirector 120. 
Other implementations for invoking redirector 120 by a bus driver call made by DCM 20 are 
possible. Network redirector 120 suppUes the drive command to a network interface card 
(NIC) 65 that interfaces with a network medium 130, e.g., a lOObaseT Ethernet cable. 
Network medium 130 is coupled with remote device 101 that is, in turn, communicatively 
coupled with a peripheral device 85. Peripheral device 85 has a peripheral address D 
associated therewith. Device 101, or the receiver device, receives and processes I/O request 
15, and issues a corresponding drive command 33 to device 85. In an exemplary 
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embodiment, a drive command network server 121 receives I/O request 15 from a network 
interface card (NIC) 66 and identifies peripheral device 85 for execution of I/O request 15 
therewith. Any retum data or error/status information generated by execution of I/O request 
15 by peripheral device 85 is preferably transmitted over network mediimi 130 and conveyed 
to application 10. Thus, embodiments of the invention enable I/O request 15 having, or 
referencing, a local peripheral address issued by an originator device 100 to be redirected to a 
remotely located device 101. The remote device 101 is coupled to peripheral device 85 
having a peripheral address D associated with remote device 101. Execution or processing of 
I/O request 15 is then performed by peripheral device 85. 

[0020] FIGURE 2 is a block diagram of device 100 as may be implemented 

according to embodiments of the invention. Device 100 stores client application 10 in a 
memory device 110. Through conventional techniques, client application 10 is executed by 
an operating system (O/S) 170 and one or more processing elements 115, such as a central 
processing unit (CPU). Operating system 170 controls the resources of device 100 and 
interfaces the instructions of application 10 with processing element 115. 

[0021] Processing element 115 communicates with and drives the other 

elements within device 100 via a local interface 180, which may comprise one or more 
busses. Furthermore, an input device 130, for example a keyboard or a pointer device, can be 
used to input data from a user of device 100, and an output device 140, for example a display 
device or a printer, can be used to output data to the user. A disk storage device 160, such as 
a magnetic disk, is connected to local interface 180 for data transfers therewith. NIC 65, such 
as an Ethemet card, is interconnected with interface 180 and provides a physical connection 
to network medium 130. 

[0022] Drive command module 20 is stored in memory device 110 or storage 

device 160 and is invoked by appUcation 10 for processing of I/O request 15. Redirector 120 
is invoked by DCM 20 and formats I/O request 15 for delivery over network medium 130. 
For example, redirector 120 may encapsulate I/O request 15 into one or more Ethemet 
packets addressed to remote device 101. The network formatted I/O request 15 is conveyed 
to a network driver, e.g., an Ethemet driver, supplied to NIC 65, and transmitted to network- 
connected remote device 101 by way of network medium 130. 

[0023] FIGURE 3 is a simplified block diagram of device 101 as may be 

implemented according to embodiments of the invention. Device 101 stores network server 
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121 in a memory device 111. Server 121 is executed by an O/S 171 and one or more 
processing elements 116 to facilitate proper operation of server 121. Operating system 171 
interfaces the instructions of server 121 with processing element 116 as necessary to enable 
server 121 to properly run. Processing element 116 commimicates with and drives the other 
elements within device 101 via a local interface 181. Device 101 may comprise an input 
device 131, an output device 141, a storage device 161 or other subsystems. A NIC 66 
included within device 101 provides a physical connection with network medium 130. 

[0024] An adapter interface 155, for example a peripheral component 

interconnect, an IDE interface, a SCSI, or another suitable peripheral interface, is 
commxmicatively coupled with processing element 1 16 by one or more busses 151, e.g., a PCI 
bus. Adapter interface 155 may be implemented as a socket, or expansion slot, and 
associated circuitry disposed on a backplane, e.g., a motherboard, of device 101 and provides 
a communication coupling or interconnection between peripheral device 85 and processing 
element 116. Memory device 111 or storage device 161 stores network server 121 
implemented as one or more computer-readable instruction set(s) executable by processing 
element 1 16. Additionally, a DCM 21 is stored in memory device 1 1 1 or storage device 161. 

[0025] Thus, for example, referring to FIGURES 1-3, according to one 

embodiment of the present invention, peripheral device 85 comprises an optical drive 200 for 
recording, reading, or otherwise processing data associated with an optical medium 210 
accessible by optical drive 200. In the illustrated embodiment, application 10 comprises 
software for accessing, reading, recording or otherwise processing data via a 
communicatively coupled optical drive. Thus, in operation, embodiments of the present 
invention enable an I/O request 15 issued from application 10, such as but not limited to, a 
record command, to be processed or otherwise executed by optical drive 200. 

[0026] With reference to FIGURE 4, a message flow diagram illustrates the 

processing of an I/O request in accordance with embodiments of the invention. Application 
10 issues I/O request 15 formatted in accordance with drive command module 20. In the 
illustrative example, drive command module 20 is implemented as an SPTI and the 
illustrative I/O request 15 comprises an SPTI-formatted DevicelOControl function call. A 
DevicelOControl I/O request is an SPTI-formatted fimction call for sending a control code to 
a specified device driver that causes a corresponding device to perform an operation specified 
by the I/O request. In general, an SPTI-formatted I/O request comprises one or more control 
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codes as function arguments of the I/O request. The control code defines the particular 
request-type of an SPTI-formatted I/O request. In the illustrative example, a control code 
IOCTL_SCSLPASS_THROUGH is included in I/O request 15 and defines I/O request 15 as 
a buffered I/O request. Additionally, I/O request 15 comprises a pointer to a SCSI request 
block (SRB) that is used in conjunction with function call DevicelOControl for fully defining 
the particular I/O request. In general, an SRB comprises a data structure for issuing 
commands to a peripheral device. Particularly, an SRB comprises members, or fields, that 
respectively comprise a value defining a parameter or characteristic of the I/O request for 
proper execution of the input/output request. A particular peripheral device with which I/O 
request 15 is to be directed is identified by one or more SRB members and may include one 
or more of a host adapter identifier, a target identifier, a logical unit number, or another SRB 
member that defines a local peripheral address that facilitates execution of I/O request 15 
with a targeted local peripheral device. For illustrative purposes, assume an SRB 125 stored 
in memory device 110 is referenced by a pointer and comprises one or more fields that 
address I/O request 15 to peripheral address C. 

10027] In accordance with embodiments of the invention, a local peripheral 

address included (or otherwise referenced) in I/O request 15 constitutes a peripheral address 
at which no peripheral device exists. I/O request 15 is received by DCM 20, e.g., a SPTI, and 
one or more drive commands 27 corresponding thereto are generated by DCM 20. DCM 20 
attempts invocation of a bus driver associated with the local peripheral address C of I/O 
request 15. In response to a bus driver call made by DCM 20, redirector 120 is invoked and 
DCM 20 passes drive command 27 thereto. Redirector 120 formats drive command 27 for 
dehvery over network medium 130. In the illustrative example, drive command 27 is 
encapsulated into one or more packets (PCK). Preferably, SRB 125 referenced by a pointer is 
encapsulated with drive command 27. In general, redirector 120 comprises logic for 
addressing a network-formatted drive command 29 (PCK(Drive command, SRB)) for 
deUvery to remote device 101. For example, a network address assigned to device 101 may 
be inserted into a header of network-formatted drive command 29. Additionally, a port 
assigned to network server 121 may be inserted into a header of network-formatted drive 
command 129. In general, network-formatted drive command 29 is conditioned for network 
delivery to network server 121 and is supplied to network medium 130 by redirector 120. 
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[0028] Network-formatted drive command 29 is conveyed to network server 

121 upon receipt by device 101. In general, network server 121 is adapted to direct execution 
of an input/output request defined by network-formatted drive command 29 with a peripheral 
device interconnected with device 101, In an exemplary embodiment, network server 121 
comprises logic for removing one or more SRB element or field values defining the local 
peripheral address to which I/O request 15 was originally directed. Preferably, network 
server 121 comprises logic for removing a peripheral address fi-om network-formatted drive 
command 29 and inserting a peripheral address assigned to peripheral device 85. For 
example, a host adapter identifier, a target identifier, and logical xmit nxmiber members 
specifying peripheral device address C included within the SRB 125 conveyed to redirector 
sever 121 are respectively removed fi-om the SRB structure and a host adapter identifier, a 
target identifier, and logical unit number members specifying peripheral address D of 
peripheral device 85 are inserted therefor. However, it should also be understood that 
redirector 120 may be configured to remove a peripheral address from network-formatted 
drive command 29 and insert a peripheral address assigned to peripheral device 85. A 
modified SRB 126 data structure having the address of peripheral device 85 is written to 
memory device 111 by network server 121. In the illustrative example, network server 121 
additionally generates a drive command module I/O request 32 corresponding to drive 
command 29. DCM I/O request 32 comprises a DevicelOControl function call corresponding 
to the function call in I/O request 15 and a pointer mssrbi that references the modified SRB 
126 written to memory device 111. Network server 121 then submits the generated DCM I/O 
request 32 to a DCM 21, e.g., an SPTI. Execution of DCM I/O request 32 is made according 
to SRB 126 referenced by pointer mssrbi, that is with peripheral device 85 targeted by the 
peripheral address inserted into SRB 126. Accordingly, DCM 21 processes I/O request 32 
and executes a drive command 33 corresponding thereto with peripheral device 85. 

[0029] A return data set 34 or error/status information may be conveyed to 

redirector sever 121 upon execution of drive command 33. In the event that return data is 
provided by peripheral device 85 upon execution of drive command 33, redirector sever 121 
preferably encapsulates return data set 34 into a packet return data set 35 and supplies the 
retum data over network medium 130. Packet return data set 35 is addressed to device 100 
and may include addressing data, e.g., a port assigned to redirector 120, for delivery of packet 
retum data set 35 to redirector 120. Upon receipt of the retum data set by redirector 120, the 
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return data set is conveyed to application 10. Accordingly, a return data set 36 is processed 
by application 10 as if the return data had been generated by a peripheral device located at the 
local peripheral address targeted by I/O request 15. That is, application 10 issues I/O request 
15 and processes any return data set 36 as if the I/O request was carried out locally on a 
peripheral device interconnected with device 100. 

[0030] As described above, I/O request 15 may be configured to reference or 

otherwise indicate a remote peripheral address associated with peripheral device 85 (e.g., a 
field within drive command 27). However, it should also be understood that the 
identification of the remote address associated with peripheral device 85 may be otherwise 
determined. For example, referring to FIGURES 1 and 2, device 100 may also comprise a 
relational database 250 accessible by redirector 120 and/or DCM 20 such that information 
associated with correlating a local peripheral address (e.g., local peripheral address C) with a 
remote address of peripheral device 85 may be retrieved or otherwise accessed. 

[0031] As described, embodiments of the invention enable an application 

running on a computer or other device interconnected with a network is able to issue 
input/output requests directed to a local peripheral device address at which no peripheral 
device exists. A redirector application receives a drive command corresponding to the 
input/output request and delivers the drive command to a network-connected remote device 
having a peripheral device interconnected therewith. An input/output request corresponding 
to the received drive command is generated by the remote device and a peripheral address 
associated with the remote device is inserted into the input/output request. Execution of the 
generated input/output request by the remote device then results in processing of the 
input/output request with the peripheral device. Accordingly, an expensive peripheral device, 
e.g., a recordable digital versatile disc drive, may be located on a network computer or other 
device. Any network connected computer having a chent application adapted to perform 
input/output requests with a local peripheral device may then issue input/output requests in a 
conventional manner without knowledge that the peripheral device is remotely located. 

[0032] Redirector 120 and drive command network server 121 are preferably 

implemented as an instruction set(s), or program, of computer-readable logic. The instruction 
set is preferably maintained on any one of various conventional computer-readable mediums. 
In the context of this document, a "computer-readable mediimi" can be any means that can 
contain, store, communicate, propagate or transport the program for use by or in connection 



200309081-1 



11 



PATENT APPLICATION 



with the instruction execution system, apparatus, or device. The computer-readable medium 
can be, for example, but is not limited to, an electronic, magnetic, optical, electro-magnetic, 
infrared, or semi-conductor system, apparatus, device, or propagation mediimi now known or 
later developed. 



